A packet with a spoofed source IP address in its header is a spoofed packet. Spoofed packets are either generated intentionally to support malicious activity or result from misconfigurations. In the former case they are used for anonymity, to reduce the risk of trace-back and to avoid attack detection by network-based sensors. It is fairly trivial for a skillful attacker to use an incorrect source IP address in attack traffic emanating from most widely-used Operating Systems. Since IP routing is destination-based, spoofed IP packets get delivered to the intended target in the same way as non-spoofed IP packets. Spoofed IP packets are particularly prevalent in Distributed Denial of Service (DDoS) attacks, wherein an attacker can compel multiple intermediate compromised hosts to inundate a target host or network with a cumulatively high-volume IP traffic stream. Detection of such DDoS attacks by network based sensors is difficult since spoofing ensures that traffic volumes from individual hosts appear to be low. In addition to high-volume attacks such as DDoS, relatively stealthy attacks may also employ spoofed IP packets. A notable example is the Slammer worm which sends out a single source IP spoofed UDP (User Datagram Protocol) packet that compromises the destination node. Spoofed IP traffic detection is a generic means by which to detect several different types of network attacks without using specialized detectors for each attack.
The construction of a source address profile for a network observation point can be accomplished by making note of source IP addresses on traffic packets observed at this observation point during some time interval. This interval is referred to as a “training period”. An issue with this approach is the possible presence of spoofed packets during the training period that could result in the construction of inaccurate source address profiles. An additional issue is the creation of incomplete profiles due to insufficient traffic being observed during the training period.
The problem of spoofed packets being present during the construction of the profile has been addressed by considering only those TCP flows that had a large number of packets. A TCP flow with a large number of packets could be indicative of the TCP handshake completed between the source and the destination, and therefore reduce the possibility of the source being spoofed. This approach is based on the assumption that large TCP flows are indicative of non-spoofed activity. However, this approach can easily be subverted by an attacker who can generate a large number of TCP packets with spoofed IP addresses. It also does not address the problem of incomplete profiles being created due to low volumes of observed traffic.
Moreover, the problem of incomplete profiles has been addressed by creating the profiles in terms of BGP Autonomous System (AS) numbers rather than source IP addresses. Since multiple IP prefixes can map to a single AS number, this allows the creation of profiles with AS numbers for unobserved IP prefixes. This approach does not address the problem of spoofed source IP addresses being observed while generating BGP AS number based profiles. Instead the approach is more focused on addressing the problem of generating profiles even when low volumes of traffic are observed while creating the profiles.
An approach to constructing Inter-Domain Packet Filters (IDPFs) that relies on edge routers constructing a set of feasible upstream neighbors for a given destination has also been tried. The set of feasible upstream neighbors is constructed based on local routing updates as received from immediate neighbors. For a given destination, the set of feasible upstream neighbors can include neighbors in addition to those actually used for sending traffic to the destination from the source in question. This approach uses local routing information only and needs to be deployed on edge routers.